src/main/java/org/example/projektarendehantering/application/service/CaseService.java (1)

328-343: occurredAt is now set twice — benign but redundant.

AuditService.record() already defaults occurredAt to Instant.now() when null (documented in AUDIT.md line 89). Setting it here is harmless but creates two sources of truth; if someone later adds server-clock-sensitive logic in record() (e.g., clock skew handling), the pre-set value will silently win. Consider either leaving it to record() or — preferably — making record() authoritative and dropping it from the builders in both CaseService and DocumentService.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@src/main/java/org/example/projektarendehantering/application/service/CaseService.java`
around lines 328 - 343, Remove the redundant occurredAt assignment in the
AuditEventEntity builder inside recordStatusChange so auditService.record(...)
can set the timestamp authoritatively; specifically, edit the recordStatusChange
method to stop calling .occurredAt(Instant.now()) on the AuditEventEntity
builder (and make the same change in DocumentService where AuditEventEntity is
built) so that AuditService.record() is the single place that populates
occurredAt.

src/main/java/org/example/projektarendehantering/presentation/web/GlobalControllerAdvice.java (2)

112-133: Validation error details are dropped.

For MethodArgumentNotValidException, the generic "Validation failed" message hides the actual field errors, which makes it difficult for API clients (and the user-facing error view) to know what to fix. Consider surfacing field-level errors from getBindingResult().getFieldErrors() for REST requests (e.g., include a fieldErrors list in the body). Same for HttpMessageNotReadableException's most-specific cause when safe to expose.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@src/main/java/org/example/projektarendehantering/presentation/web/GlobalControllerAdvice.java`
around lines 112 - 133, In handleBadRequestException in GlobalControllerAdvice,
don't return only the generic "Validation failed": when e is a
MethodArgumentNotValidException extract field errors via
((MethodArgumentNotValidException)e).getBindingResult().getFieldErrors() and
include a serializable fieldErrors list (field, rejectedValue, defaultMessage)
in the REST ResponseEntity body and also add it to the Model for non-REST views;
for HttpMessageNotReadableException include the most-specific safe cause message
(e.getMostSpecificCause().getMessage()) in the response as an additional detail
property (only for REST or sanitized for views) so clients receive actionable
error details.

---

106-110: 404 handler bypasses REST/HTML response conventions.

Unlike the other handlers in this class, handleNoResourceFoundException returns void with @ResponseStatus, so Spring falls back to its default error dispatch (e.g. BasicErrorController) instead of producing the JSON body {errorCode, message, status} used by /api/** callers or the error view used elsewhere. If REST clients rely on the consistent error envelope, a missing API path will now return a differently-shaped response than e.g. AccessDeniedException or the new handleBadRequestException.

Consider mirroring the REST/HTML branching used in the neighboring handlers if consistency matters:

♻️ Suggested shape

-    `@ExceptionHandler`(NoResourceFoundException.class)
-    `@ResponseStatus`(HttpStatus.NOT_FOUND)
-    public void handleNoResourceFoundException(NoResourceFoundException e) {
-        // Just return 404, don't log as ERROR
-    }
+    `@ExceptionHandler`(NoResourceFoundException.class)
+    public Object handleNoResourceFoundException(NoResourceFoundException e,
+                                                 HttpServletRequest request,
+                                                 HttpServletResponse response,
+                                                 Model model) {
+        HttpStatus status = HttpStatus.NOT_FOUND;
+        if (isRestRequest(request)) {
+            return ResponseEntity.status(status).body(Map.of(
+                    "errorCode", "NOT_FOUND",
+                    "message", "Resource not found",
+                    "status", status.value()));
+        }
+        response.setStatus(status.value());
+        model.addAttribute("status", status.value() + " " + status.getReasonPhrase());
+        model.addAttribute("message", "Resource not found");
+        model.addAttribute("errorCode", "NOT_FOUND");
+        return "error";
+    }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@src/main/java/org/example/projektarendehantering/presentation/web/GlobalControllerAdvice.java`
around lines 106 - 110, The NoResourceFoundException handler currently returns
void with `@ResponseStatus` which triggers Spring's default error dispatch; update
handleNoResourceFoundException(NoResourceFoundException e) to mirror the
neighboring handlers' REST/HTML branching: accept HttpServletRequest (and
optionally HttpServletResponse), detect API requests (e.g.
request.getServletPath().startsWith("/api/") or check Accept header), and for
API callers return the same JSON error envelope used elsewhere (errorCode,
message, status) as a ResponseEntity, while for non-API callers return the same
error view (ModelAndView "error") used by the other handlers so responses are
consistent across clients. Ensure you reuse the same error envelope construction
logic and view name used by the other handlers in this class.

src/test/java/org/example/projektarendehantering/ProjektArendehanteringApplicationTests.java (1)

40-46: Brittle assumption about 200 OK for missing body.

The comment says the endpoint returns 200 because the body is missing (re-renders the form). This is a behavioral coupling — if /ui/cases/new ever validates CSRF + empty body and redirects/returns 4xx, the test will fail for reasons unrelated to auditing. Since the intent here is only to assert that a mutation produces an audit row, consider asserting status().is2xxSuccessful() (or a broader matcher) so the test remains focused on the audit count delta.

-        mockMvc.perform(post("/ui/cases/new").with(csrf()))
-                .andExpect(status().isOk()); // Returns 200 (re-renders form) because body is missing
+        mockMvc.perform(post("/ui/cases/new").with(csrf()));
+        // Status intentionally not asserted; this test only verifies that
+        // mutation requests produce an audit event.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@src/test/java/org/example/projektarendehantering/ProjektArendehanteringApplicationTests.java`
around lines 40 - 46, The test assumes a 200 OK for
mockMvc.perform(post("/ui/cases/new").with(csrf())) which is brittle; change the
status assertion to a broader 2xx check (e.g., use status().is2xxSuccessful())
so the test remains focused on the auditEventRepository.count() delta and not
the exact response behavior; update the assertion around mockMvc.perform(...)
and keep the subsequent assertThat(after).isGreaterThan(before) as-is.

AUDIT.md (1)

70-82: Interceptor description no longer mentions eventName/description.

Step 3 was updated to drop HTTP method, but the interceptor now also sets eventName = "WEB_ACTION" and description = "<method> <requestURI>". Adding a step (or note) here would keep the workflow description accurate and discoverable.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@AUDIT.md` around lines 70 - 82, The audit doc's "Building the event" steps
omit that the interceptor now sets eventName and description; update the section
(near the list of fields like actorId/principalName and the step about request
metadata) to state that the interceptor sets eventName = "WEB_ACTION" and
description = "<method> <requestURI>" (i.e., HTTP method followed by the request
URI), so the documentation reflects the actual behavior of the interceptor that
also constructs these two fields.

src/test/java/org/example/projektarendehantering/AuditIntegrationTest.java (1)

60-68: Consider asserting the new eventName and description fields.

The PR introduces eventName ("WEB_ACTION") and description (" ") on audit events, but the integration test no longer asserts either. Adding lightweight assertions (e.g., assertThat(latest.getEventName()).isEqualTo("WEB_ACTION"); and assertThat(latest.getDescription()).contains("POST").contains("/api/cases");) would lock in the new contract and catch regressions in the interceptor.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/test/java/org/example/projektarendehantering/AuditIntegrationTest.java`
around lines 60 - 68, AuditIntegrationTest currently checks the persisted
AuditEventEntity via auditEventRepository but misses assertions for the new
fields; update the test to assert the new eventName and description contract by
adding assertions on the retrieved AuditEventEntity (latest) such as asserting
latest.getEventName().equals("WEB_ACTION") and that latest.getDescription()
contains the HTTP method and path (e.g., contains("POST") and
contains("/api/cases")), keeping the existing requestPath assertion via
latest.getRequestPath() to validate the interceptor behavior.

src/main/resources/templates/audit/list.html (1)

65-65: #strings.substring on a UUID relies on implicit toString().

e.caseId is likely a UUID, not a String. Thymeleaf's #strings.substring generally coerces via toString(), but being explicit avoids surprises and is more robust. Also consider using ${#strings.abbreviate(e.caseId, 11)} or similar for the '...' affordance.

Proposed fix

-                    <a th:if="${e.caseId != null}" th:href="@{/ui/cases/{id}(id=${e.caseId})}" th:text="${`#strings.substring`(e.caseId,0,8)} + '...'">case</a>
+                    <a th:if="${e.caseId != null}" th:href="@{/ui/cases/{id}(id=${e.caseId})}" th:text="${`#strings.substring`(e.caseId.toString(),0,8) + '...'}">case</a>

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/main/resources/templates/audit/list.html` at line 65, The template
currently calls `#strings.substring` on e.caseId which may be a UUID; explicitly
convert e.caseId to string (e.g., use e.caseId.toString()) before substring to
avoid implicit coercion, or replace the expression with Thymeleaf's
`#strings.abbreviate`(e.caseId.toString(), 11) to produce a safe 8-char + '...'
display; update the expression that references e.caseId and the
`#strings.substring/`#strings.abbreviate call accordingly.

src/main/java/org/example/projektarendehantering/infrastructure/web/AuditInterceptor.java (1)

60-61: Description duplicates fields already captured; consider sanitizing path tokens.

description is "<method> <requestURI>", while requestPath already stores the URI and the HTTP method is implicit in the mutation filter. If the goal is a human-readable summary, consider a more meaningful value (e.g., handler-derived action). Additionally, requestURI can embed sensitive path variables (tokens, emails); AuditService only sanitizes queryString, so such values will land unsanitized in description. Worth confirming this is acceptable for your audit retention/PII posture.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@src/main/java/org/example/projektarendehantering/infrastructure/web/AuditInterceptor.java`
around lines 60 - 61, The description currently duplicates requestPath and may
leak sensitive path variables: update the AuditInterceptor so
event.setDescription(...) does not include raw request.getRequestURI(); instead
derive a concise human-readable action (e.g., handler or controller method name)
or sanitize path tokens before setting description; reference the
event.setDescription call and request.getRequestURI usage and either replace it
with a handler-derived value (use the handler/controller info available in the
interceptor) or run the URI through the same sanitization used for queryString
in AuditService so requestPath and description remain safe and non-duplicative.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

src/main/java/org/example/projektarendehantering/application/service/AuditService.java (1)

118-129: Returning a pre-failed emitter back to Spring MVC.

If the initial "connected" event fails, the emitter is removed from emitters but still returned to the controller, which hands it to Spring MVC. Depending on the failure state, downstream logging may be noisy and the client gets a broken stream without a clear signal. Consider calling emitter.completeWithError(e) and returning early (or letting the IOException propagate) so the client sees a clean failure and Spring doesn't attempt to drive a dead emitter:

🛠️ Proposed fix

         } catch (IOException e) {
             log.error("Failed to send initial SSE event", e);
             emitters.remove(emitter);
+            emitter.completeWithError(e);
         }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@src/main/java/org/example/projektarendehantering/application/service/AuditService.java`
around lines 118 - 129, The code currently removes the failed SseEmitter
(emitter) from the emitters set but still returns it to the controller; change
the error handling in the block that sends the initial "connected" event so that
on IOException you call emitter.completeWithError(e) (or rethrow the
IOException) and return early instead of returning the (now-broken) emitter;
update the method that constructs the emitter (the code surrounding emitter,
emitters, and the try/catch that sends the "connected" event in AuditService) to
ensure the failed emitter is not returned to Spring MVC and that the exception
is propagated or an explicit null/clean failure is returned.

src/main/resources/templates/fragments/header.html (1)

44-84: Stream is opened for managers on every page regardless of endpoint access.

Every non-/ui/audit page load for a manager opens a long-lived SSE connection to /api/audit/stream. Combined with the server side's single global emitter list and 30‑minute timeout, this can accumulate one connection per open tab per manager, multiplying server resources needed (threads/connections) and audit broadcast work. Consider opening the stream only on a dedicated page (or a shared worker), or closing it on visibilitychange/pagehide to bound resource usage.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@src/main/resources/templates/fragments/header.html` around lines 44 - 84, The
SSE is being opened on every page because the current pathname check is
inverted; change the guard to only create EventSource when on the audit page
(replace if (window.location.pathname === '/ui/audit') return; with if
(window.location.pathname !== '/ui/audit') return;), and add lifecycle cleanup:
after creating const eventSource = new EventSource('/api/audit/stream');
register document.addEventListener('visibilitychange', ...) and
window.addEventListener('pagehide', ...) handlers that call eventSource.close(),
and also ensure eventSource.onerror continues to close on terminal states;
reference the eventSource variable, the '/api/audit/stream' URL, and the
'auditLink' click handler for coordination.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

src/main/java/org/example/projektarendehantering/infrastructure/config/AuditWebMvcConfig.java (1)

22-22: Consider scoping the CSRF eager-init interceptor to the same paths as auditing.

csrfEagerInitInterceptor is registered without any addPathPatterns(...)/excludePathPatterns(...), so it runs for every request including /static/**, /app.css, /app.js, /error**, and /login**. The work it does is cheap, but it's inconsistent with the narrower scope applied to auditInterceptor and means the CSRF token is eagerly generated on requests that don't need it (e.g., static asset fetches).

If the motivation is to ensure the token cookie is set on pages that will later make mutating API calls, scoping this to /ui/** and /api/** (mirroring the audit interceptor) would be cleaner and avoid unnecessary work on static/error/login paths.

♻️ Proposed scoping

-        registry.addInterceptor(csrfEagerInitInterceptor);
+        registry.addInterceptor(csrfEagerInitInterceptor)
+                .addPathPatterns("/ui/**", "/api/**")
+                .excludePathPatterns(
+                        "/static/**",
+                        "/app.css",
+                        "/app.js",
+                        "/error**",
+                        "/login**"
+                );

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@src/main/java/org/example/projektarendehantering/infrastructure/config/AuditWebMvcConfig.java`
at line 22, The csrfEagerInitInterceptor is registered globally via
registry.addInterceptor(csrfEagerInitInterceptor) causing it to run on all
requests (static, error, login); scope it the same as auditInterceptor by
registering with path patterns (e.g., addPathPatterns("/ui/**", "/api/**")) or
the existing patterns used for auditInterceptor inside AuditWebMvcConfig so the
CSRF eager-init only runs for the UI/API paths that need it and avoids
static/error/login requests.

src/main/java/org/example/projektarendehantering/infrastructure/config/SecurityConfig.java (1)

58-63: Consider using a RequestMatcher that respects context path.

request.getRequestURI() includes the servlet context path, so if the application is ever deployed under a non-root context (e.g., /app), requests to /app/api/... won't match and will fall through to the default entry point (login redirect). Using Spring's AntPathRequestMatcher / PathPatternRequestMatcher would handle this correctly and also be consistent with the authorizeHttpRequests matchers above.

♻️ Suggested refactor

-            .exceptionHandling(ex -> ex
-                .defaultAuthenticationEntryPointFor(
-                    new HttpStatusEntryPoint(HttpStatus.UNAUTHORIZED),
-                    request -> request.getRequestURI().startsWith("/api/")
-                )
-            )
+            .exceptionHandling(ex -> ex
+                .defaultAuthenticationEntryPointFor(
+                    new HttpStatusEntryPoint(HttpStatus.UNAUTHORIZED),
+                    new AntPathRequestMatcher("/api/**")
+                )
+            )

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@src/main/java/org/example/projektarendehantering/infrastructure/config/SecurityConfig.java`
around lines 58 - 63, The exception handling uses a lambda with
request.getRequestURI() which ignores servlet context path; update
SecurityConfig's exceptionHandling/defaultAuthenticationEntryPointFor to use a
RequestMatcher that respects context path (e.g., new
AntPathRequestMatcher("/api/**") or PathPatternRequestMatcher("/api/**"))
instead of the request -> request.getRequestURI().startsWith("/api/") predicate
so the HttpStatusEntryPoint(HttpStatus.UNAUTHORIZED) is applied correctly when
the app is deployed under a non-root context.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

src/main/java/org/example/projektarendehantering/presentation/web/GlobalControllerAdvice.java (1)

117-138: Consider surfacing validation error details.

For MethodArgumentNotValidException, the binding result (field errors, rejected values) is discarded and replaced with a generic "Validation failed" message. API clients typically need the per-field details to render actionable feedback. Consider extracting e.getBindingResult().getFieldErrors() into the response body for REST requests.

♻️ Suggested enhancement

     `@ExceptionHandler`({HttpMessageNotReadableException.class, MethodArgumentNotValidException.class})
     public Object handleBadRequestException(Exception e, HttpServletRequest request, HttpServletResponse response, Model model) {
         HttpStatus status = HttpStatus.BAD_REQUEST;
         String message = "Invalid request payload";
-        if (e instanceof MethodArgumentNotValidException) {
+        Map<String, String> fieldErrors = Map.of();
+        if (e instanceof MethodArgumentNotValidException manv) {
             message = "Validation failed";
+            fieldErrors = manv.getBindingResult().getFieldErrors().stream()
+                    .collect(java.util.stream.Collectors.toMap(
+                            org.springframework.validation.FieldError::getField,
+                            fe -> fe.getDefaultMessage() != null ? fe.getDefaultMessage() : "invalid",
+                            (a, b) -> a));
         }
 
         if (isRestRequest(request)) {
             return ResponseEntity.status(status)
                     .body(Map.of(
                             "errorCode", "BAD_REQUEST",
                             "message", message,
-                            "status", status.value()
+                            "status", status.value(),
+                            "errors", fieldErrors
                     ));
         }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@src/main/java/org/example/projektarendehantering/presentation/web/GlobalControllerAdvice.java`
around lines 117 - 138, The handler handleBadRequestException currently returns
a generic "Validation failed" for MethodArgumentNotValidException; modify it to
extract field details from
((MethodArgumentNotValidException)e).getBindingResult().getFieldErrors() and
include a structured "errors" array (field, rejectedValue, defaultMessage) in
the REST ResponseEntity body (when isRestRequest(request) is true), while
preserving the existing errorCode/message/status; keep non-REST behavior
unchanged. Use the class/field names MethodArgumentNotValidException,
getBindingResult(), getFieldErrors(), isRestRequest(request), and ResponseEntity
to locate and implement the change.

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes